Hi Brad,
I think the problem might be here at the end:
Jog(axis,0); // stop
MoveRelAtVel(axis,sensoroffset * oppdir,speed);
EnableAxisDest(axis,0);
Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
Please add waits between these
while (!CheckDone(axis)) ;
Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
Regards
TK
| Group: DynoMotion |
Message: 3832 |
From: Brad Murry |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom, That worked perfectly. I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before. Here is the procedure for calibrating an axis on this machine:: Step 1 Home axis Step 2 Jog axis to the origin and press Save origin button(which just grabs the current position and saves it) Step 3 Jog to 6” intervals from origin and log those positions Step 4 Once the position table is filled, the axis can be commanded to a requested position. Step 5 The requested position is calculated from the table and a ‘calibrated’ position is actually sent to the axis. This seems to works perfectly on one side of the table, but not the other. On the ‘bad’ table 1 motor is positioning reliably, but two are seemingly random. I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position. Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place. When I re-home and jog the axis back to the origin it reports a different dest! I’ve had them re check that everything is tight mechanically and I am told that it is. Not sure what to do here….. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Friday, February 10, 2012 12:35 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] homing inconsistencies I think the problem might be here at the end: Jog(axis,0); // stop
MoveRelAtVel(axis,sensoroffset * oppdir,speed);
EnableAxisDest(axis,0); Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now. Please add waits between these while (!CheckDone(axis)) ; Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor. Hello Tom,
I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
Could this value need adjustment? ::
FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
Here is a snippet of the homing routine::
void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
main()
{
DoHome( 5, // Laser #5
100, // speed steps/sec
1, // direction to home
172, // home input bit
1, // bit polarity (0 or 1) when tripped
1000); // amount to move back inside (counts)
}
void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
{
float oppdir = dir * -1;
EnableAxis(axis);
if(ReadBit(bit)==polarity)
{
Jog(axis, speed * oppdir); // start moving
while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
Jog(axis,0); // stop
MoveRelAtVel(axis,sensoroffset * oppdir,speed);
}
Jog(axis, speed * dir); // start moving
while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
Jog(axis,0); // stop
MoveRelAtVel(axis,sensoroffset * oppdir,speed);
EnableAxisDest(axis,0);
}
Please help
-Brad Murry |
|
| Group: DynoMotion |
Message: 3835 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
I added in some motion logic to make sure the lasers are being position from the same direction every time.
Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Tom,
>
>
>
> That worked perfectly.
>
>
>
>
>
> I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
>
>
>
> Here is the procedure for calibrating an axis on this machine::
>
>
>
> Step 1
>
>
>
> Home axis
>
>
>
> Step 2
>
> Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
>
>
>
> Step 3
>
> Jog to 6â intervals from origin and log those positions
>
>
>
> Step 4
>
> Once the position table is filled, the axis can be commanded to a requested position.
>
>
>
> Step 5
>
> The requested position is calculated from the table and a âcalibratedâ position is actually sent to the axis.
>
>
>
>
>
>
>
> This seems to works perfectly on one side of the table, but not the other. On the âbadâ table 1 motor is positioning reliably, but two are seemingly random.
>
>
>
> I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
>
> Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
>
>
>
> When I re-home and jog the axis back to the origin it reports a different dest!
>
>
>
>
>
> Iâve had them re check that everything is tight mechanically and I am told that it is.
>
>
>
> Not sure what to do hereâ¦..
>
>
>
> -Brad Murry
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 12:35 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> I think the problem might be here at the end:
>
>
>
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
>
> Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
>
>
>
> Please add waits between these
>
>
>
> while (!CheckDone(axis)) ;
>
>
>
> Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 11:11 AM
> Subject: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hello Tom,
>
> I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
>
> I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
>
> Could this value need adjustment? ::
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
> Here is a snippet of the homing routine::
>
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
>
> main()
> {
>
>
> DoHome( 5, // Laser #5
> 100, // speed steps/sec
> 1, // direction to home
> 172, // home input bit
> 1, // bit polarity (0 or 1) when tripped
> 1000); // amount to move back inside (counts)
>
>
> }
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> {
> float oppdir = dir * -1;
>
> EnableAxis(axis);
> if(ReadBit(bit)==polarity)
> {
> Jog(axis, speed * oppdir); // start moving
> while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> }
> Jog(axis, speed * dir); // start moving
> while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
> }
>
> Please help
>
> -Brad Murry
> |
|
| Group: DynoMotion |
Message: 3839 |
From: Tom Kerekes |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hi Brad,
Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
TK
| Group: DynoMotion |
Message: 3840 |
From: Brad Murry |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
I think it has to do with reversal. As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a “creeping” of final position was observed by the tech when commanding the motor to the same position over and over. So it happens like this:: Commanded move = 12 Actual first move = 12.5 Wait until done Then back to 12 When this is repeated over and over it seems to “creep” as observed by the laser projection(but the Dest value in KMotionEXE is consistent). -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Friday, February 10, 2012 2:48 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: homing inconsistencies Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal. I added in some motion logic to make sure the lasers are being position from the same direction every time.
Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Tom,
>
>
>
> That worked perfectly.
>
>
>
>
>
> I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
>
>
>
> Here is the procedure for calibrating an axis on this machine::
>
>
>
> Step 1
>
>
>
> Home axis
>
>
>
> Step 2
>
> Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
>
>
>
> Step 3
>
> Jog to 6” intervals from origin and log those positions
>
>
>
> Step 4
>
> Once the position table is filled, the axis can be commanded to a requested position.
>
>
>
> Step 5
>
> The requested position is calculated from the table and a ‘calibrated’ position is actually sent to the axis.
>
>
>
>
>
>
>
> This seems to works perfectly on one side of the table, but not the other. On the ‘bad’ table 1 motor is positioning reliably, but two are seemingly random.
>
>
>
> I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
>
> Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
>
>
>
> When I re-home and jog the axis back to the origin it reports a different dest!
>
>
>
>
>
> I’ve had them re check that everything is tight mechanically and I am told that it is.
>
>
>
> Not sure what to do here…..
>
>
>
> -Brad Murry
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 12:35 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> I think the problem might be here at the end:
>
>
>
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
>
> Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
>
>
>
> Please add waits between these
>
>
>
> while (!CheckDone(axis)) ;
>
>
>
> Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 11:11 AM
> Subject: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hello Tom,
>
> I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
>
> I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
>
> Could this value need adjustment? ::
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
> Here is a snippet of the homing routine::
>
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
>
> main()
> {
>
>
> DoHome( 5, // Laser #5
> 100, // speed steps/sec
> 1, // direction to home
> 172, // home input bit
> 1, // bit polarity (0 or 1) when tripped
> 1000); // amount to move back inside (counts)
>
>
> }
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> {
> float oppdir = dir * -1;
>
> EnableAxis(axis);
> if(ReadBit(bit)==polarity)
> {
> Jog(axis, speed * oppdir); // start moving
> while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> }
> Jog(axis, speed * dir); // start moving
> while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
> }
>
> Please help
>
> -Brad Murry
> |
|
| Group: DynoMotion |
Message: 3842 |
From: TK |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Are you inverting the Step Pulse with the FPGA setting in your C code?
TK
I think it has to do with reversal. As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a “creeping” of final position was observed by the tech when commanding the motor to the same position over and over. So it happens like this:: Commanded move = 12 Actual first move = 12.5 Wait until done Then back to 12 When this is repeated over and over it seems to “creep” as observed by the laser projection(but the Dest value in KMotionEXE is consistent). -Brad Murry Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal. I added in some motion logic to make sure the lasers are being position from the same direction every time.
Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Tom,
>
>
>
> That worked perfectly.
>
>
>
>
>
> I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
>
>
>
> Here is the procedure for calibrating an axis on this machine::
>
>
>
> Step 1
>
>
>
> Home axis
>
>
>
> Step 2
>
> Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
>
>
>
> Step 3
>
> Jog to 6” intervals from origin and log those positions
>
>
>
> Step 4
>
> Once the position table is filled, the axis can be commanded to a requested position.
>
>
>
> Step 5
>
> The requested position is calculated from the table and a ‘calibrated’ position is actually sent to the axis.
>
>
>
>
>
>
>
> This seems to works perfectly on one side of the table, but not the other. On the ‘bad’ table 1 motor is positioning reliably, but two are seemingly random.
>
>
>
> I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
>
> Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
>
>
>
> When I re-home and jog the axis back to the origin it reports a different dest!
>
>
>
>
>
> I’ve had them re check that everything is tight mechanically and I am told that it is.
>
>
>
> Not sure what to do here…..
>
>
>
> -Brad Murry
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 12:35 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> I think the problem might be here at the end:
>
>
>
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
>
> Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
>
>
>
> Please add waits between these
>
>
>
> while (!CheckDone(axis)) ;
>
>
>
> Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 11:11 AM
> Subject: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hello Tom,
>
> I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
>
> I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
>
> Could this value need adjustment? ::
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
> Here is a snippet of the homing routine::
>
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
>
> main()
> {
>
>
> DoHome( 5, // Laser #5
> 100, // speed steps/sec
> 1, // direction to home
> 172, // home input bit
> 1, // bit polarity (0 or 1) when tripped
> 1000); // amount to move back inside (counts)
>
>
> }
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> {
> float oppdir = dir * -1;
>
> EnableAxis(axis);
> if(ReadBit(bit)==polarity)
> {
> Jog(axis, speed * oppdir); // start moving
> while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> }
> Jog(axis, speed * dir); // start moving
> while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
> }
>
> Please help
>
> -Brad Murry
>
|
|
| Group: DynoMotion |
Message: 3843 |
From: Brad Murry |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
This is one of the first lines in main() FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
Sent: Friday, February 10, 2012 3:14 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: homing inconsistencies Are you inverting the Step Pulse with the FPGA setting in your C code?
TK I think it has to do with reversal. As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a “creeping” of final position was observed by the tech when commanding the motor to the same position over and over. So it happens like this:: Commanded move = 12 Actual first move = 12.5 Wait until done Then back to 12 When this is repeated over and over it seems to “creep” as observed by the laser projection(but the Dest value in KMotionEXE is consistent). -Brad Murry Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal. I added in some motion logic to make sure the lasers are being position from the same direction every time.
Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Tom,
>
>
>
> That worked perfectly.
>
>
>
>
>
> I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
>
>
>
> Here is the procedure for calibrating an axis on this machine::
>
>
>
> Step 1
>
>
>
> Home axis
>
>
>
> Step 2
>
> Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
>
>
>
> Step 3
>
> Jog to 6” intervals from origin and log those positions
>
>
>
> Step 4
>
> Once the position table is filled, the axis can be commanded to a requested position.
>
>
>
> Step 5
>
> The requested position is calculated from the table and a ‘calibrated’ position is actually sent to the axis.
>
>
>
>
>
>
>
> This seems to works perfectly on one side of the table, but not the other. On the ‘bad’ table 1 motor is positioning reliably, but two are seemingly random.
>
>
>
> I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
>
> Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
>
>
>
> When I re-home and jog the axis back to the origin it reports a different dest!
>
>
>
>
>
> I’ve had them re check that everything is tight mechanically and I am told that it is.
>
>
>
> Not sure what to do here…..
>
>
>
> -Brad Murry
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 12:35 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> I think the problem might be here at the end:
>
>
>
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
>
> Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
>
>
>
> Please add waits between these
>
>
>
> while (!CheckDone(axis)) ;
>
>
>
> Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 11:11 AM
> Subject: [DynoMotion] homing inconsistencies
>
>
>
>
>
> Hello Tom,
>
> I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
>
> I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
>
> Could this value need adjustment? ::
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
> Here is a snippet of the homing routine::
>
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
>
> main()
> {
>
>
> DoHome( 5, // Laser #5
> 100, // speed steps/sec
> 1, // direction to home
> 172, // home input bit
> 1, // bit polarity (0 or 1) when tripped
> 1000); // amount to move back inside (counts)
>
>
> }
> void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> {
> float oppdir = dir * -1;
>
> EnableAxis(axis);
> if(ReadBit(bit)==polarity)
> {
> Jog(axis, speed * oppdir); // start moving
> while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> }
> Jog(axis, speed * dir); // start moving
> while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> Jog(axis,0); // stop
> MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> EnableAxisDest(axis,0);
> }
>
> Please help
>
> -Brad Murry
>
|
|
| Group: DynoMotion |
Message: 3844 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom,
This is the acutal start after headers::
int main()
{
double T0, LastX=0, LastY=0, LastZ=0, Tau;
KStepPresent=TRUE; // enable KSTEP input multiplexing
FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
ch0->InputMode=NO_INPUT_MODE;
... and so on to configure the rest of the axis settings.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> This is one of the first lines in main()
>
>
>
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> Sent: Friday, February 10, 2012 3:14 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> Are you inverting the Step Pulse with the FPGA setting in your C code?
>
> TK
>
>
> On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@...> wrote:
>
>
>
> I think it has to do with reversal.
>
>
>
> As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a âcreepingâ of final position was observed by the tech when commanding the motor to the same position over and over.
>
>
>
> So it happens like this::
>
>
>
> Commanded move = 12
>
>
>
> Actual first move = 12.5
>
> Wait until done
>
> Then back to 12
>
>
>
> When this is repeated over and over it seems to âcreepâ as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 2:48 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
>
>
>
> TK
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 1:20 PM
> Subject: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> I added in some motion logic to make sure the lasers are being position from the same direction every time.
>
> Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
>
> I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
>
> -Brad Murry
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> >
> > Hello Tom,
> >
> >
> >
> > That worked perfectly.
> >
> >
> >
> >
> >
> > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> >
> >
> >
> > Here is the procedure for calibrating an axis on this machine::
> >
> >
> >
> > Step 1
> >
> >
> >
> > Home axis
> >
> >
> >
> > Step 2
> >
> > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> >
> >
> >
> > Step 3
> >
> > Jog to 6â intervals from origin and log those positions
> >
> >
> >
> > Step 4
> >
> > Once the position table is filled, the axis can be commanded to a requested position.
> >
> >
> >
> > Step 5
> >
> > The requested position is calculated from the table and a âcalibratedâ position is actually sent to the axis.
> >
> >
> >
> >
> >
> >
> >
> > This seems to works perfectly on one side of the table, but not the other. On the âbadâ table 1 motor is positioning reliably, but two are seemingly random.
> >
> >
> >
> > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> >
> > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> >
> >
> >
> > When I re-home and jog the axis back to the origin it reports a different dest!
> >
> >
> >
> >
> >
> > Iâve had them re check that everything is tight mechanically and I am told that it is.
> >
> >
> >
> > Not sure what to do hereâ¦..
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > Sent: Friday, February 10, 2012 12:35 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: Re: [DynoMotion] homing inconsistencies
> >
> >
> >
> >
> >
> > Hi Brad,
> >
> >
> >
> > I think the problem might be here at the end:
> >
> >
> >
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > EnableAxisDest(axis,0);
> >
> > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> >
> >
> >
> > Please add waits between these
> >
> >
> >
> > while (!CheckDone(axis)) ;
> >
> >
> >
> > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> >
> >
> >
> > Regards
> >
> > TK
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: bradodarb <bradodarb@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Friday, February 10, 2012 11:11 AM
> > Subject: [DynoMotion] homing inconsistencies
> >
> >
> >
> >
> >
> > Hello Tom,
> >
> > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> >
> > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> >
> > Could this value need adjustment? ::
> > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> >
> > Here is a snippet of the homing routine::
> >
> > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> >
> > main()
> > {
> >
> >
> > DoHome( 5, // Laser #5
> > 100, // speed steps/sec
> > 1, // direction to home
> > 172, // home input bit
> > 1, // bit polarity (0 or 1) when tripped
> > 1000); // amount to move back inside (counts)
> >
> >
> > }
> > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > {
> > float oppdir = dir * -1;
> >
> > EnableAxis(axis);
> > if(ReadBit(bit)==polarity)
> > {
> > Jog(axis, speed * oppdir); // start moving
> > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > }
> > Jog(axis, speed * dir); // start moving
> > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > EnableAxisDest(axis,0);
> > }
> >
> > Please help
> >
> > -Brad Murry
> >
>
>
>
> Reply to <mailto:bradodarb@...?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
>
> Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
>
> Recent Activity:
>
> * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
>
> <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
> |
|
| Group: DynoMotion |
Message: 3845 |
From: TK |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
That should be what is required. But you might try removing the 0x80 in case I'm wrong. Also increase the 32 to the max of 63 to see if that helps.
Otherwise can you move reliably from KMotion.exe?
Maybe you are doing something strange like re-enabling the axis every move or something?
TK
Hello Tom,
This is the acutal start after headers::
int main()
{
double T0, LastX=0, LastY=0, LastZ=0, Tau;
KStepPresent=TRUE; // enable KSTEP input multiplexing
FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
ch0->InputMode=NO_INPUT_MODE;
... and so on to configure the rest of the axis settings.
-Brad Murry
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> This is one of the first lines in main()
>
>
>
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> Sent: Friday, February 10, 2012 3:14 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> Are you inverting the Step Pulse with the FPGA setting in your C code?
>
> TK
>
>
> On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@...> wrote:
>
>
>
> I think it has to do with reversal.
>
>
>
> As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a “creeping†of final position was observed by the tech when commanding the motor to the same position over and over.
>
>
>
> So it happens like this::
>
>
>
> Commanded move = 12
>
>
>
> Actual first move = 12.5
>
> Wait until done
>
> Then back to 12
>
>
>
> When this is repeated over and over it seems to “creep†as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, February 10, 2012 2:48 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> Hi Brad,
>
>
>
> Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
>
>
>
> TK
>
>
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 1:20 PM
> Subject: [DynoMotion] Re: homing inconsistencies
>
>
>
>
>
> I added in some motion logic to make sure the lasers are being position from the same direction every time.
>
> Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
>
> I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
>
> -Brad Murry
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> >
> > Hello Tom,
> >
> >
> >
> > That worked perfectly.
> >
> >
> >
> >
> >
> > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> >
> >
> >
> > Here is the procedure for calibrating an axis on this machine::
> >
> >
> >
> > Step 1
> >
> >
> >
> > Home axis
> >
> >
> >
> > Step 2
> >
> > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> >
> >
> >
> > Step 3
> >
> > Jog to 6†intervals from origin and log those positions
> >
> >
> >
> > Step 4
> >
> > Once the position table is filled, the axis can be commanded to a requested position.
> >
> >
> >
> > Step 5
> >
> > The requested position is calculated from the table and a ‘calibrated’ position is actually sent to the axis.
> >
> >
> >
> >
> >
> >
> >
> > This seems to works perfectly on one side of the table, but not the other. On the ‘bad’ table 1 motor is positioning reliably, but two are seemingly random.
> >
> >
> >
> > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> >
> > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> >
> >
> >
> > When I re-home and jog the axis back to the origin it reports a different dest!
> >
> >
> >
> >
> >
> > I’ve had them re check that everything is tight mechanically and I am told that it is.
> >
> >
> >
> > Not sure what to do here…..
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > Sent: Friday, February 10, 2012 12:35 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: Re: [DynoMotion] homing inconsistencies
> >
> >
> >
> >
> >
> > Hi Brad,
> >
> >
> >
> > I think the problem might be here at the end:
> >
> >
> >
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > EnableAxisDest(axis,0);
> >
> > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> >
> >
> >
> > Please add waits between these
> >
> >
> >
> > while (!CheckDone(axis)) ;
> >
> >
> >
> > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> >
> >
> >
> > Regards
> >
> > TK
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: bradodarb <bradodarb@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Friday, February 10, 2012 11:11 AM
> > Subject: [DynoMotion] homing inconsistencies
> >
> >
> >
> >
> >
> > Hello Tom,
> >
> > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> >
> > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> >
> > Could this value need adjustment? ::
> > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> >
> > Here is a snippet of the homing routine::
> >
> > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> >
> > main()
> > {
> >
> >
> > DoHome( 5, // Laser #5
> > 100, // speed steps/sec
> > 1, // direction to home
> > 172, // home input bit
> > 1, // bit polarity (0 or 1) when tripped
> > 1000); // amount to move back inside (counts)
> >
> >
> > }
> > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > {
> > float oppdir = dir * -1;
> >
> > EnableAxis(axis);
> > if(ReadBit(bit)==polarity)
> > {
> > Jog(axis, speed * oppdir); // start moving
> > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > }
> > Jog(axis, speed * dir); // start moving
> > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > Jog(axis,0); // stop
> > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > EnableAxisDest(axis,0);
> > }
> >
> > Please help
> >
> > -Brad Murry
> >
>
>
>
> Reply to <mailto:bradodarb@...?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
>
> Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
>
> Recent Activity:
>
> * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
>
> <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
>
|
|
| Group: DynoMotion |
Message: 3846 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom,
I made the recommended change but still no joy.
Then I decided to double check in KMotion.exe as suggested and I plugged in this code::
#include "KMotionDef.h"
main()
{
MoveAtVel(2,35.5, 1000);
while(!CheckDone(2));
MoveAtVel(2, 60.0,100);
}
It yields the same 'creepy' results.
I am at a total loss, as the machine performs to spec on the other four motors.
I guess I can try a different channel?
-Brad Murry
--- In DynoMotion@yahoogroups.com, TK <tk@...> wrote:
>
> That should be what is required. But you might try removing the 0x80 in case I'm wrong. Also increase the 32 to the max of 63 to see if that helps.
>
> Otherwise can you move reliably from KMotion.exe?
>
> Maybe you are doing something strange like re-enabling the axis every move or something?
>
> TK
>
> On Feb 10, 2012, at 2:18 PM, "bradodarb" <bradodarb@...> wrote:
>
> > Hello Tom,
> >
> > This is the acutal start after headers::
> >
> > int main()
> > {
> > double T0, LastX=0, LastY=0, LastZ=0, Tau;
> >
> > KStepPresent=TRUE; // enable KSTEP input multiplexing
> > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > ch0->InputMode=NO_INPUT_MODE;
> >
> > ... and so on to configure the rest of the axis settings.
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > This is one of the first lines in main()
> > >
> > >
> > >
> > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> > > Sent: Friday, February 10, 2012 3:14 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > >
> > >
> > >
> > >
> > >
> > > Are you inverting the Step Pulse with the FPGA setting in your C code?
> > >
> > > TK
> > >
> > >
> > > On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@> wrote:
> > >
> > >
> > >
> > > I think it has to do with reversal.
> > >
> > >
> > >
> > > As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a ââ¬Å"creepingââ¬Â of final position was observed by the tech when commanding the motor to the same position over and over.
> > >
> > >
> > >
> > > So it happens like this::
> > >
> > >
> > >
> > > Commanded move = 12
> > >
> > >
> > >
> > > Actual first move = 12.5
> > >
> > > Wait until done
> > >
> > > Then back to 12
> > >
> > >
> > >
> > > When this is repeated over and over it seems to ââ¬Å"creepââ¬Â as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > Sent: Friday, February 10, 2012 2:48 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > >
> > >
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
> > >
> > >
> > >
> > > TK
> > >
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, February 10, 2012 1:20 PM
> > > Subject: [DynoMotion] Re: homing inconsistencies
> > >
> > >
> > >
> > >
> > >
> > > I added in some motion logic to make sure the lasers are being position from the same direction every time.
> > >
> > > Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
> > >
> > > I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
> > >
> > > -Brad Murry
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> > > >
> > > > Hello Tom,
> > > >
> > > >
> > > >
> > > > That worked perfectly.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> > > >
> > > >
> > > >
> > > > Here is the procedure for calibrating an axis on this machine::
> > > >
> > > >
> > > >
> > > > Step 1
> > > >
> > > >
> > > >
> > > > Home axis
> > > >
> > > >
> > > >
> > > > Step 2
> > > >
> > > > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> > > >
> > > >
> > > >
> > > > Step 3
> > > >
> > > > Jog to 6ââ¬Â intervals from origin and log those positions
> > > >
> > > >
> > > >
> > > > Step 4
> > > >
> > > > Once the position table is filled, the axis can be commanded to a requested position.
> > > >
> > > >
> > > >
> > > > Step 5
> > > >
> > > > The requested position is calculated from the table and a ââ¬Ëcalibratedââ¬â¢ position is actually sent to the axis.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > This seems to works perfectly on one side of the table, but not the other. On the ââ¬Ëbadââ¬â¢ table 1 motor is positioning reliably, but two are seemingly random.
> > > >
> > > >
> > > >
> > > > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> > > >
> > > > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> > > >
> > > >
> > > >
> > > > When I re-home and jog the axis back to the origin it reports a different dest!
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Iââ¬â¢ve had them re check that everything is tight mechanically and I am told that it is.
> > > >
> > > >
> > > >
> > > > Not sure what to do hereââ¬Â¦..
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > > > Sent: Friday, February 10, 2012 12:35 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: Re: [DynoMotion] homing inconsistencies
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi Brad,
> > > >
> > > >
> > > >
> > > > I think the problem might be here at the end:
> > > >
> > > >
> > > >
> > > > Jog(axis,0); // stop
> > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > EnableAxisDest(axis,0);
> > > >
> > > > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> > > >
> > > >
> > > >
> > > > Please add waits between these
> > > >
> > > >
> > > >
> > > > while (!CheckDone(axis)) ;
> > > >
> > > >
> > > >
> > > > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> > > >
> > > >
> > > >
> > > > Regards
> > > >
> > > > TK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Sent: Friday, February 10, 2012 11:11 AM
> > > > Subject: [DynoMotion] homing inconsistencies
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hello Tom,
> > > >
> > > > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> > > >
> > > > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> > > >
> > > > Could this value need adjustment? ::
> > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > >
> > > > Here is a snippet of the homing routine::
> > > >
> > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> > > >
> > > > main()
> > > > {
> > > >
> > > >
> > > > DoHome( 5, // Laser #5
> > > > 100, // speed steps/sec
> > > > 1, // direction to home
> > > > 172, // home input bit
> > > > 1, // bit polarity (0 or 1) when tripped
> > > > 1000); // amount to move back inside (counts)
> > > >
> > > >
> > > > }
> > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > > > {
> > > > float oppdir = dir * -1;
> > > >
> > > > EnableAxis(axis);
> > > > if(ReadBit(bit)==polarity)
> > > > {
> > > > Jog(axis, speed * oppdir); // start moving
> > > > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > > > Jog(axis,0); // stop
> > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > }
> > > > Jog(axis, speed * dir); // start moving
> > > > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > > > Jog(axis,0); // stop
> > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > EnableAxisDest(axis,0);
> > > > }
> > > >
> > > > Please help
> > > >
> > > > -Brad Murry
> > > >
> > >
> > >
> > >
> > > Reply to <mailto:bradodarb@?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
> > >
> > > Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
> > >
> > > Recent Activity:
> > >
> > > * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> > > * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> > > * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
> > >
> > > <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
> > >
> >
> >
> > Reply to sender | Reply to group |
> |
|
| Group: DynoMotion |
Message: 3847 |
From: Tom Kerekes |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hi Brad,
Which FPGA settings did you test that C program with?
How much is the "creep" ?
Is it consistant?
The 35.5 position is a bit odd as we can't move a fraction of a microstep but should not be a problem.
Regards
TK
| Group: DynoMotion |
Message: 3848 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom,
using::
FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32;
cause a creep in one direction
and
FPGA(STEP_PULSE_LENGTH_ADD) = 63;
creeps the other way.
I set the counts to ints (35 <-> 60).
-Brad Murry
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
> Â
> Which FPGA settings did you test that C program with?
> Â
> How much is the "creep" ?
> Â
> Is it consistant?
> Â
> The 35.5 position is a bit odd as we can't move a fraction of a microstep but should not be a problem.
> Â
> Regards
> TK
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, February 10, 2012 2:42 PM
> Subject: [DynoMotion] Re: homing inconsistencies
>
>
> Â
> Hello Tom,
>
> I made the recommended change but still no joy.
>
> Then I decided to double check in KMotion.exe as suggested and I plugged in this code::
>
> #include "KMotionDef.h"
>
> main()
> {
> MoveAtVel(2,35.5, 1000);
> while(!CheckDone(2));
> MoveAtVel(2, 60.0,100);
> }
>
> It yields the same 'creepy' results.
>
> I am at a total loss, as the machine performs to spec on the other four motors.
>
> I guess I can try a different channel?
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, TK <tk@> wrote:
> >
> > That should be what is required. But you might try removing the 0x80 in case I'm wrong. Also increase the 32 to the max of 63 to see if that helps.
> >
> > Otherwise can you move reliably from KMotion.exe?
> >
> > Maybe you are doing something strange like re-enabling the axis every move or something?
> >
> > TK
> >
> > On Feb 10, 2012, at 2:18 PM, "bradodarb" <bradodarb@> wrote:
> >
> > > Hello Tom,
> > >
> > > This is the acutal start after headers::
> > >
> > > int main()
> > > {
> > > double T0, LastX=0, LastY=0, LastZ=0, Tau;
> > >
> > > KStepPresent=TRUE; // enable KSTEP input multiplexing
> > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > ch0->InputMode=NO_INPUT_MODE;
> > >
> > > ... and so on to configure the rest of the axis settings.
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > > >
> > > > This is one of the first lines in main()
> > > >
> > > >
> > > >
> > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> > > > Sent: Friday, February 10, 2012 3:14 PM
> > > > To: DynoMotion@yahoogroups.com
> > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Are you inverting the Step Pulse with the FPGA setting in your C code?
> > > >
> > > > TK
> > > >
> > > >
> > > > On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@> wrote:
> > > >
> > > >
> > > >
> > > > I think it has to do with reversal.
> > > >
> > > >
> > > >
> > > > As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a âââ¬Ã
"creepingâââ¬Ã� of final position was observed by the tech when commanding the motor to the same position over and over.
> > > >
> > > >
> > > >
> > > > So it happens like this::
> > > >
> > > >
> > > >
> > > > Commanded move = 12
> > > >
> > > >
> > > >
> > > > Actual first move = 12.5
> > > >
> > > > Wait until done
> > > >
> > > > Then back to 12
> > > >
> > > >
> > > >
> > > > When this is repeated over and over it seems to âââ¬Ã
"creepâââ¬Ã� as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > > Sent: Friday, February 10, 2012 2:48 PM
> > > > To: DynoMotion@yahoogroups.com
> > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi Brad,
> > > >
> > > >
> > > >
> > > > Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
> > > >
> > > >
> > > >
> > > > TK
> > > >
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Friday, February 10, 2012 1:20 PM
> > > > Subject: [DynoMotion] Re: homing inconsistencies
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I added in some motion logic to make sure the lasers are being position from the same direction every time.
> > > >
> > > > Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
> > > >
> > > > I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
> > > >
> > > > -Brad Murry
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > >
> > > > >
> > > > > That worked perfectly.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> > > > >
> > > > >
> > > > >
> > > > > Here is the procedure for calibrating an axis on this machine::
> > > > >
> > > > >
> > > > >
> > > > > Step 1
> > > > >
> > > > >
> > > > >
> > > > > Home axis
> > > > >
> > > > >
> > > > >
> > > > > Step 2
> > > > >
> > > > > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> > > > >
> > > > >
> > > > >
> > > > > Step 3
> > > > >
> > > > > Jog to 6âââ¬Ã� intervals from origin and log those positions
> > > > >
> > > > >
> > > > >
> > > > > Step 4
> > > > >
> > > > > Once the position table is filled, the axis can be commanded to a requested position.
> > > > >
> > > > >
> > > > >
> > > > > Step 5
> > > > >
> > > > > The requested position is calculated from the table and a âââ¬ÃÅ"calibratedâââ‰â¢ position is actually sent to the axis.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > This seems to works perfectly on one side of the table, but not the other. On the âââ¬ÃÅ"badâââ‰â¢ table 1 motor is positioning reliably, but two are seemingly random.
> > > > >
> > > > >
> > > > >
> > > > > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> > > > >
> > > > > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> > > > >
> > > > >
> > > > >
> > > > > When I re-home and jog the axis back to the origin it reports a different dest!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Iâââ‰â¢ve had them re check that everything is tight mechanically and I am told that it is.
> > > > >
> > > > >
> > > > >
> > > > > Not sure what to do hereâââ¬Ã¦..
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > > > > Sent: Friday, February 10, 2012 12:35 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: Re: [DynoMotion] homing inconsistencies
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi Brad,
> > > > >
> > > > >
> > > > >
> > > > > I think the problem might be here at the end:
> > > > >
> > > > >
> > > > >
> > > > > Jog(axis,0); // stop
> > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > EnableAxisDest(axis,0);
> > > > >
> > > > > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> > > > >
> > > > >
> > > > >
> > > > > Please add waits between these
> > > > >
> > > > >
> > > > >
> > > > > while (!CheckDone(axis)) ;
> > > > >
> > > > >
> > > > >
> > > > > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> > > > >
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > Sent: Friday, February 10, 2012 11:11 AM
> > > > > Subject: [DynoMotion] homing inconsistencies
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> > > > >
> > > > > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> > > > >
> > > > > Could this value need adjustment? ::
> > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > >
> > > > > Here is a snippet of the homing routine::
> > > > >
> > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> > > > >
> > > > > main()
> > > > > {
> > > > >
> > > > >
> > > > > DoHome( 5, // Laser #5
> > > > > 100, // speed steps/sec
> > > > > 1, // direction to home
> > > > > 172, // home input bit
> > > > > 1, // bit polarity (0 or 1) when tripped
> > > > > 1000); // amount to move back inside (counts)
> > > > >
> > > > >
> > > > > }
> > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > > > > {
> > > > > float oppdir = dir * -1;
> > > > >
> > > > > EnableAxis(axis);
> > > > > if(ReadBit(bit)==polarity)
> > > > > {
> > > > > Jog(axis, speed * oppdir); // start moving
> > > > > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > > > > Jog(axis,0); // stop
> > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > }
> > > > > Jog(axis, speed * dir); // start moving
> > > > > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > > > > Jog(axis,0); // stop
> > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > EnableAxisDest(axis,0);
> > > > > }
> > > > >
> > > > > Please help
> > > > >
> > > > > -Brad Murry
> > > > >
> > > >
> > > >
> > > >
> > > > Reply to <mailto:bradodarb@?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
> > > >
> > > > Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
> > > >
> > > > Recent Activity:
> > > >
> > > > * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> > > > * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> > > > * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
> > > >
> > > > <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
> > > >
> > >
> > >
> > > Reply to sender | Reply to group |
> >
> |
|
| Group: DynoMotion |
Message: 3849 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom,
You know how sometimes when you are bleeding from bashing your head against the wall and you jst start playing with values?
Well I try not to do that but then I decided to try this::
FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 63;
Which you may have suggested, but I read your response as remove the 0x80 and crank it up to 63.
Anyhow, it seems to have done the trick and all is well.
Thanks again Tom,
-Brad Murry
--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello Tom,
>
>
> using::
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32;
>
> cause a creep in one direction
>
> and
>
> FPGA(STEP_PULSE_LENGTH_ADD) = 63;
>
> creeps the other way.
>
>
>
> I set the counts to ints (35 <-> 60).
>
> -Brad Murry
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Brad,
> > Â
> > Which FPGA settings did you test that C program with?
> > Â
> > How much is the "creep" ?
> > Â
> > Is it consistant?
> > Â
> > The 35.5 position is a bit odd as we can't move a fraction of a microstep but should not be a problem.
> > Â
> > Regards
> > TK
> >
> > From: bradodarb <bradodarb@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, February 10, 2012 2:42 PM
> > Subject: [DynoMotion] Re: homing inconsistencies
> >
> >
> > Â
> > Hello Tom,
> >
> > I made the recommended change but still no joy.
> >
> > Then I decided to double check in KMotion.exe as suggested and I plugged in this code::
> >
> > #include "KMotionDef.h"
> >
> > main()
> > {
> > MoveAtVel(2,35.5, 1000);
> > while(!CheckDone(2));
> > MoveAtVel(2, 60.0,100);
> > }
> >
> > It yields the same 'creepy' results.
> >
> > I am at a total loss, as the machine performs to spec on the other four motors.
> >
> > I guess I can try a different channel?
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, TK <tk@> wrote:
> > >
> > > That should be what is required. But you might try removing the 0x80 in case I'm wrong. Also increase the 32 to the max of 63 to see if that helps.
> > >
> > > Otherwise can you move reliably from KMotion.exe?
> > >
> > > Maybe you are doing something strange like re-enabling the axis every move or something?
> > >
> > > TK
> > >
> > > On Feb 10, 2012, at 2:18 PM, "bradodarb" <bradodarb@> wrote:
> > >
> > > > Hello Tom,
> > > >
> > > > This is the acutal start after headers::
> > > >
> > > > int main()
> > > > {
> > > > double T0, LastX=0, LastY=0, LastZ=0, Tau;
> > > >
> > > > KStepPresent=TRUE; // enable KSTEP input multiplexing
> > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > ch0->InputMode=NO_INPUT_MODE;
> > > >
> > > > ... and so on to configure the rest of the axis settings.
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > This is one of the first lines in main()
> > > > >
> > > > >
> > > > >
> > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> > > > > Sent: Friday, February 10, 2012 3:14 PM
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Are you inverting the Step Pulse with the FPGA setting in your C code?
> > > > >
> > > > > TK
> > > > >
> > > > >
> > > > > On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@> wrote:
> > > > >
> > > > >
> > > > >
> > > > > I think it has to do with reversal.
> > > > >
> > > > >
> > > > >
> > > > > As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a âââ¬Ã
"creepingâââ¬Ã� of final position was observed by the tech when commanding the motor to the same position over and over.
> > > > >
> > > > >
> > > > >
> > > > > So it happens like this::
> > > > >
> > > > >
> > > > >
> > > > > Commanded move = 12
> > > > >
> > > > >
> > > > >
> > > > > Actual first move = 12.5
> > > > >
> > > > > Wait until done
> > > > >
> > > > > Then back to 12
> > > > >
> > > > >
> > > > >
> > > > > When this is repeated over and over it seems to âââ¬Ã
"creepâââ¬Ã� as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > > > Sent: Friday, February 10, 2012 2:48 PM
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi Brad,
> > > > >
> > > > >
> > > > >
> > > > > Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
> > > > >
> > > > >
> > > > >
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Friday, February 10, 2012 1:20 PM
> > > > > Subject: [DynoMotion] Re: homing inconsistencies
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I added in some motion logic to make sure the lasers are being position from the same direction every time.
> > > > >
> > > > > Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
> > > > >
> > > > > I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
> > > > >
> > > > > -Brad Murry
> > > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > >
> > > > > >
> > > > > > That worked perfectly.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Here is the procedure for calibrating an axis on this machine::
> > > > > >
> > > > > >
> > > > > >
> > > > > > Step 1
> > > > > >
> > > > > >
> > > > > >
> > > > > > Home axis
> > > > > >
> > > > > >
> > > > > >
> > > > > > Step 2
> > > > > >
> > > > > > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> > > > > >
> > > > > >
> > > > > >
> > > > > > Step 3
> > > > > >
> > > > > > Jog to 6âââ¬Ã� intervals from origin and log those positions
> > > > > >
> > > > > >
> > > > > >
> > > > > > Step 4
> > > > > >
> > > > > > Once the position table is filled, the axis can be commanded to a requested position.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Step 5
> > > > > >
> > > > > > The requested position is calculated from the table and a âââ¬ÃÅ"calibratedâââ‰â¢ position is actually sent to the axis.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > This seems to works perfectly on one side of the table, but not the other. On the âââ¬ÃÅ"badâââ‰â¢ table 1 motor is positioning reliably, but two are seemingly random.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> > > > > >
> > > > > > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> > > > > >
> > > > > >
> > > > > >
> > > > > > When I re-home and jog the axis back to the origin it reports a different dest!
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Iâââ‰â¢ve had them re check that everything is tight mechanically and I am told that it is.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Not sure what to do hereâââ¬Ã¦..
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > > > > > Sent: Friday, February 10, 2012 12:35 PM
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: Re: [DynoMotion] homing inconsistencies
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Brad,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think the problem might be here at the end:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Jog(axis,0); // stop
> > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > EnableAxisDest(axis,0);
> > > > > >
> > > > > > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please add waits between these
> > > > > >
> > > > > >
> > > > > >
> > > > > > while (!CheckDone(axis)) ;
> > > > > >
> > > > > >
> > > > > >
> > > > > > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: bradodarb <bradodarb@>
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Sent: Friday, February 10, 2012 11:11 AM
> > > > > > Subject: [DynoMotion] homing inconsistencies
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> > > > > >
> > > > > > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> > > > > >
> > > > > > Could this value need adjustment? ::
> > > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > > >
> > > > > > Here is a snippet of the homing routine::
> > > > > >
> > > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> > > > > >
> > > > > > main()
> > > > > > {
> > > > > >
> > > > > >
> > > > > > DoHome( 5, // Laser #5
> > > > > > 100, // speed steps/sec
> > > > > > 1, // direction to home
> > > > > > 172, // home input bit
> > > > > > 1, // bit polarity (0 or 1) when tripped
> > > > > > 1000); // amount to move back inside (counts)
> > > > > >
> > > > > >
> > > > > > }
> > > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > > > > > {
> > > > > > float oppdir = dir * -1;
> > > > > >
> > > > > > EnableAxis(axis);
> > > > > > if(ReadBit(bit)==polarity)
> > > > > > {
> > > > > > Jog(axis, speed * oppdir); // start moving
> > > > > > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > > > > > Jog(axis,0); // stop
> > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > }
> > > > > > Jog(axis, speed * dir); // start moving
> > > > > > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > > > > > Jog(axis,0); // stop
> > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > EnableAxisDest(axis,0);
> > > > > > }
> > > > > >
> > > > > > Please help
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > Reply to <mailto:bradodarb@?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
> > > > >
> > > > > Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
> > > > >
> > > > > Recent Activity:
> > > > >
> > > > > * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> > > > > * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> > > > > * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
> > > > >
> > > > > <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
> > > > >
> > > >
> > > >
> > > > Reply to sender | Reply to group |
> > >
> >
> |
|
| Group: DynoMotion |
Message: 3850 |
From: bradodarb |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hello Tom,
Where can I find info on the FPGA structures. I would really like to know more about what is going on there.
-Brad Murry
--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello Tom,
>
> You know how sometimes when you are bleeding from bashing your head against the wall and you jst start playing with values?
>
> Well I try not to do that but then I decided to try this::
>
> FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 63;
>
>
> Which you may have suggested, but I read your response as remove the 0x80 and crank it up to 63.
>
>
> Anyhow, it seems to have done the trick and all is well.
>
> Thanks again Tom,
>
> -Brad Murry
>
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Hello Tom,
> >
> >
> > using::
> > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32;
> >
> > cause a creep in one direction
> >
> > and
> >
> > FPGA(STEP_PULSE_LENGTH_ADD) = 63;
> >
> > creeps the other way.
> >
> >
> >
> > I set the counts to ints (35 <-> 60).
> >
> > -Brad Murry
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Brad,
> > > Â
> > > Which FPGA settings did you test that C program with?
> > > Â
> > > How much is the "creep" ?
> > > Â
> > > Is it consistant?
> > > Â
> > > The 35.5 position is a bit odd as we can't move a fraction of a microstep but should not be a problem.
> > > Â
> > > Regards
> > > TK
> > >
> > > From: bradodarb <bradodarb@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, February 10, 2012 2:42 PM
> > > Subject: [DynoMotion] Re: homing inconsistencies
> > >
> > >
> > > Â
> > > Hello Tom,
> > >
> > > I made the recommended change but still no joy.
> > >
> > > Then I decided to double check in KMotion.exe as suggested and I plugged in this code::
> > >
> > > #include "KMotionDef.h"
> > >
> > > main()
> > > {
> > > MoveAtVel(2,35.5, 1000);
> > > while(!CheckDone(2));
> > > MoveAtVel(2, 60.0,100);
> > > }
> > >
> > > It yields the same 'creepy' results.
> > >
> > > I am at a total loss, as the machine performs to spec on the other four motors.
> > >
> > > I guess I can try a different channel?
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, TK <tk@> wrote:
> > > >
> > > > That should be what is required. But you might try removing the 0x80 in case I'm wrong. Also increase the 32 to the max of 63 to see if that helps.
> > > >
> > > > Otherwise can you move reliably from KMotion.exe?
> > > >
> > > > Maybe you are doing something strange like re-enabling the axis every move or something?
> > > >
> > > > TK
> > > >
> > > > On Feb 10, 2012, at 2:18 PM, "bradodarb" <bradodarb@> wrote:
> > > >
> > > > > Hello Tom,
> > > > >
> > > > > This is the acutal start after headers::
> > > > >
> > > > > int main()
> > > > > {
> > > > > double T0, LastX=0, LastY=0, LastZ=0, Tau;
> > > > >
> > > > > KStepPresent=TRUE; // enable KSTEP input multiplexing
> > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > > ch0->InputMode=NO_INPUT_MODE;
> > > > >
> > > > > ... and so on to configure the rest of the axis settings.
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > This is one of the first lines in main()
> > > > > >
> > > > > >
> > > > > >
> > > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of TK
> > > > > > Sent: Friday, February 10, 2012 3:14 PM
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Are you inverting the Step Pulse with the FPGA setting in your C code?
> > > > > >
> > > > > > TK
> > > > > >
> > > > > >
> > > > > > On Feb 10, 2012, at 1:52 PM, Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think it has to do with reversal.
> > > > > >
> > > > > >
> > > > > >
> > > > > > As I said in a previous mail when I changed the motion to overshot by a distance and then come back to the desired position, a âââ¬Ã
"creepingâââ¬Ã� of final position was observed by the tech when commanding the motor to the same position over and over.
> > > > > >
> > > > > >
> > > > > >
> > > > > > So it happens like this::
> > > > > >
> > > > > >
> > > > > >
> > > > > > Commanded move = 12
> > > > > >
> > > > > >
> > > > > >
> > > > > > Actual first move = 12.5
> > > > > >
> > > > > > Wait until done
> > > > > >
> > > > > > Then back to 12
> > > > > >
> > > > > >
> > > > > >
> > > > > > When this is repeated over and over it seems to âââ¬Ã
"creepâââ¬Ã� as observed by the laser projection(but the Dest value in KMotionEXE is consistent).
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > > > > Sent: Friday, February 10, 2012 2:48 PM
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Subject: Re: [DynoMotion] Re: homing inconsistencies
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Brad,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Again sounds like a mis-step problem. If a stepper mis-steps it will be off by 4 full steps or 64 uSteps. Is that what you are seeing? It could be too high acceleration or something on the reversal.
> > > > > >
> > > > > >
> > > > > >
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: bradodarb <bradodarb@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Friday, February 10, 2012 1:20 PM
> > > > > > Subject: [DynoMotion] Re: homing inconsistencies
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I added in some motion logic to make sure the lasers are being position from the same direction every time.
> > > > > >
> > > > > > Basically when a position is commande, I overshoot it by .5" and then come back to the requested position.
> > > > > >
> > > > > > I was just informed that on the two problematic motors that commanding the same position over and over causes creep in the actual position. The dest stays consistent, but the position in reality creeps.
> > > > > >
> > > > > > -Brad Murry
> > > > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> > > > > > >
> > > > > > > Hello Tom,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > That worked perfectly.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I am still experiencing some odd issues on some of the motors, and I wonder if there is some saturation issue because the moves are so small like you said before.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Here is the procedure for calibrating an axis on this machine::
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Step 1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Home axis
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Step 2
> > > > > > >
> > > > > > > Jog axis to the origin and press Save origin button(which just grabs the current position and saves it)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Step 3
> > > > > > >
> > > > > > > Jog to 6âââ¬Ã� intervals from origin and log those positions
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Step 4
> > > > > > >
> > > > > > > Once the position table is filled, the axis can be commanded to a requested position.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Step 5
> > > > > > >
> > > > > > > The requested position is calculated from the table and a âââ¬ÃÅ"calibratedâââ‰â¢ position is actually sent to the axis.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This seems to works perfectly on one side of the table, but not the other. On the âââ¬ÃÅ"badâââ‰â¢ table 1 motor is positioning reliably, but two are seemingly random.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I can go through steps 1-2 and if I tell it the part size is 0(which should command to the origin) it does not always reach that position.
> > > > > > >
> > > > > > > Sometimes if I re-home the problem axis it will go to the right position. In every case, it does display the dest value that I command it to, but seems to arrive at a different place.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > When I re-home and jog the axis back to the origin it reports a different dest!
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Iâââ‰â¢ve had them re check that everything is tight mechanically and I am told that it is.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Not sure what to do hereâââ¬Ã¦..
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > > > > > > Sent: Friday, February 10, 2012 12:35 PM
> > > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Subject: Re: [DynoMotion] homing inconsistencies
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Brad,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I think the problem might be here at the end:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Jog(axis,0); // stop
> > > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > > EnableAxisDest(axis,0);
> > > > > > >
> > > > > > > Jog commands or Move commands do not wait for the action to complete they only initiate the action. So the result is we are telling KFLOP to Stop smoothly, then no no no, Move over here, then no no no Stop instantly and reset the position to zero right now.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Please add waits between these
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > while (!CheckDone(axis)) ;
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Also the stop is not really needed. The MoveRel should perform a blended turnaround to the point inside the sensor.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > TK
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: bradodarb <bradodarb@>
> > > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Sent: Friday, February 10, 2012 11:11 AM
> > > > > > > Subject: [DynoMotion] homing inconsistencies
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hello Tom,
> > > > > > >
> > > > > > > I am having some issues with homing. It seems that I can home an axis several times and it does not home at the exact spot every time.
> > > > > > >
> > > > > > > I switched over to a modified simple home thinking it was the HomeMMV8 that was the problem.
> > > > > > >
> > > > > > > Could this value need adjustment? ::
> > > > > > > FPGA(STEP_PULSE_LENGTH_ADD) = 0x80 + 32; // set inverted and to 2us
> > > > > > >
> > > > > > > Here is a snippet of the homing routine::
> > > > > > >
> > > > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset);
> > > > > > >
> > > > > > > main()
> > > > > > > {
> > > > > > >
> > > > > > >
> > > > > > > DoHome( 5, // Laser #5
> > > > > > > 100, // speed steps/sec
> > > > > > > 1, // direction to home
> > > > > > > 172, // home input bit
> > > > > > > 1, // bit polarity (0 or 1) when tripped
> > > > > > > 1000); // amount to move back inside (counts)
> > > > > > >
> > > > > > >
> > > > > > > }
> > > > > > > void DoHome(int axis, float speed, int dir, int bit, int polarity, float sensoroffset)
> > > > > > > {
> > > > > > > float oppdir = dir * -1;
> > > > > > >
> > > > > > > EnableAxis(axis);
> > > > > > > if(ReadBit(bit)==polarity)
> > > > > > > {
> > > > > > > Jog(axis, speed * oppdir); // start moving
> > > > > > > while (ReadBit(bit) == polarity) ; // wait for switch (input #8) to change
> > > > > > > Jog(axis,0); // stop
> > > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > > }
> > > > > > > Jog(axis, speed * dir); // start moving
> > > > > > > while (ReadBit(bit) != polarity) ; // wait for switch (input #8) to change
> > > > > > > Jog(axis,0); // stop
> > > > > > > MoveRelAtVel(axis,sensoroffset * oppdir,speed);
> > > > > > > EnableAxisDest(axis,0);
> > > > > > > }
> > > > > > >
> > > > > > > Please help
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Reply to <mailto:bradodarb@?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> sender | Reply to <mailto:DynoMotion@yahoogroups.com?subject=RE%3A%20%5BDynoMotion%5D%20Re%3A%20homing%20inconsistencies> group | Reply <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJxY2ZvOWhnBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMyODkxMDc2Mg--?act=reply&messageNum=3840> via web post | <http://groups.yahoo.com/group/DynoMotion/post;_ylc=X3oDMTJmNjNzbTNyBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMjg5MTA3NjI-> Start a New Topic
> > > > > >
> > > > > > Messages in this topic <http://groups.yahoo.com/group/DynoMotion/message/3830;_ylc=X3oDMTM1ZGx2Zm9yBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMzODQwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMyODkxMDc2MgR0cGNJZAMzODMw> (6)
> > > > > >
> > > > > > Recent Activity:
> > > > > >
> > > > > > * <http://groups.yahoo.com/group/DynoMotion/members;_ylc=X3oDMTJnMDQ4Y3YxBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzI4OTEwNzYy?o=6> New Members 5
> > > > > > * <http://groups.yahoo.com/group/DynoMotion/spnew;_ylc=X3oDMTJnMG84MTkzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzI4OTEwNzYy> New Photos 2
> > > > > > * <http://groups.yahoo.com/group/DynoMotion/files;_ylc=X3oDMTJocG9wZG04BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTMyODkxMDc2Mg--> New Files 3
> > > > > >
> > > > > > <http://groups.yahoo.com/group/DynoMotion;_ylc=X3oDMTJmaWR2YWZwBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMjg5MTA3NjI-> Visit Your Group
> > > > > >
> > > > >
> > > > >
> > > > > Reply to sender | Reply to group |
> > > >
> > >
> >
> |
|
| Group: DynoMotion |
Message: 3851 |
From: Tom Kerekes |
Date: 2/10/2012 |
| Subject: Re: homing inconsistencies |
Hi Brad,
The FPGA registers are listed in KMoionDef.h
But in this case the functionality for the Step/Dir Generators is described here:
A 2us setup time for the Direction signal should be sufficient so I'm not sure what is going on.
Regards
TK
| | | | | | | |
